In content protection schemes used for viewing premium AV sources (such as DVD, BlueRay, etc.), revocation list is used to verify whether a device (e.g., TV) is valid and genuinely authorized to have the right to receive and show the protected premium media content (e.g., AV content); however, the use of the revocation list is often not secure and can be a drain on the system resources. For example, a revocation list can be used by a DVD player to detect whether a receiving device, such as a TV, is legal or eligible to receive protected media content from the DVD player. If the unique information associated with the device is not in the revocation list then the device is not regarded an illegal device, thus the protected content is sent; otherwise, the content is not sent. However, an attacker or hacker can fairly easily alter the communication data between checking the revocation list and verifying it to cause consequential interruption and misdirection of data.
One technique would be to make the system closed system, such as putting the revocation list and verification engine in a chip and to process any verification tasks only inside of or on the chip to prevent the hacker from accessing the relevant information. However, one problem with performing the task on the chip is it can add more than 5K bytes to, for example, store the revocation list and that can negatively impact the efficiency of not only signature verification process but also other process within the system. Hence, it is desired to have a system that can perform secure verification of revocation list within a closed and protected system without having to store the entire revocation list on the chip.
FIG. 1 illustrates a conventional content protection scheme 100. In content protection scheme 100, a revocation list is used to detect devices that are known to be illegal or ineligible (e.g., compromised) and stop its operation. For example, transmitting system 102 including a transmission device 104 (e.g., DVD player) and firmware (FW) 106 checks the unique information associated with a receiving device 110 (e.g., TV) of receiving system 108 (having FW 112) to determine whether the receiving device 110 is a valid device and is authorized to receive protected media contents from the transmitting device 104. The determining of whether the receiving device 110 is authorized includes verifying unique information associated with the receiving device 110 that is provided in the revocation list. If the unique information is not verified, the receiving device 110 is refrained from receiving any of the protected media content from the transmitting device 104. Similar processes are performed on the receiving side as the receiving device 110 and firmware 112 verify the transmitting system 102 before communicating with it.
For example, in the illustrated content protection scheme 100, on the transmission side, at the transmitter system 102, the revocation list is fetched by the transmitting FW 106 running, for example, in u-controller to check the signature associated with the transmitting device 110, such as using (Elliptic Curve Digital Signature Algorithm (ECDSA) for Elliptic Curve Cryptography (ECC) 116. On the transmitting firmware side 106, a revocation list is received 114 and then, the signature check is performed 118. The process includes comparing the signature of IdB 124 (associated with the receiving device 110) with the one in the revocation list. If the signature check fails, the transmitting device 104 is stopped 120 from sending any protected content to the receiving device 110. On the other hand, if the signature passes the test, the transmitting FW 106 notifies “pass” to the transmitting device 104 to perform subsequent verification processes. A test to verify the unique identification (unique ID) associated with the receiving device 112 is performed at the transmitting device 104, such as using Elliptic Curve Digital Signature Algorithm-Signature Verification (ECDSAverif) 126. If the unique ID fails the signature verification test, the process is stopped 128 and “fail” is notified. If the unique ID passes the verification and does not match with any one on the revocation list, the process is labeled “pass” and is moved on to the next phase 130.
As illustrated, similar verification processes are also performed on the receiving end of the system by the receiving system 108 to verify the validity and eligibility of the transmitting system 102. The transmitting and receiving systems 102, 108 exchange certificates 138, 140 as a proof of validation of the counterpart system or device.
At least one problem with this content protection scheme 100 is the level of security when the communication is performed between FW 106 and 112 with devices 104 and 110 as indicated by IdB 124 and IdA 142, respectively, such as thru local I2C 132, 148 that is vulnerable to alterations and attacks by hackers. These problem areas are marked by large asterisks 134, 136, 144, 146. Such an attack or alteration can change the IdB 124 and IdA 142 being communicated to FW 106, 112 to pass the comparing phase and/or the final result (e.g., pass/fail) being communicated to devices 104, 110 as shown by asterisks 134, 136, 144, 146.
Such alteration of communication information can paralyze the entire security system and could allow an illegal device to transmit and/or receive protected media content. Thus, it is desirable to have a secure signature checking and unique ID comparison system that is performed on the chip itself providing a closed and more secure system that rids of the necessity to move critical information between FW 106, 112 and devices 104, 110.
It is, therefore, desirable to have a content protection system that is secure and can be protected from hackers without having to add memory space or other burdens to the system.